在發這篇時，今天已經是鐵人賽第15天，後面15天該如何撰寫，如果在鐵人賽前沒有規劃，真的是寫到哪算到哪。

另外在整理文章時，也發現原來要做的實驗，都遇到了受管理網路的問題而無法實作。

像是辦公室使用iTaiwan，像是家中使用第四台寬頻，都是非固定WAN ip的環境，所以連port forwarding設定後，疑似網路提供商那邊還有一次NAT，造成無法實現WAN IP container服務。

而host網路就是跟本機HOST一樣的網路配置，也是有這樣的問題，可見就不是因為container架構所造成的。

這邊就暫時只能說明WAN IP的撰寫因為實驗環境而導致無法繼續實驗下去了...

不過還是可以肯定以下作法一定可以達成WAN IP看得到container服務。

1. bridge mode:HOST本身有WAN ip設定，可以下bind ip，再加上publish port。外面看到的是HOST的IP。
2. host mode:HOST本身有WAN ip設定，--network=host，就直接讓container的port對外服務。外面看到的是HOST的IP。
3. reverse proxy或有外部的負載平衡設備：可以用VIP,RIP mapping的方式，讓使用內部ip的container也可以對外。(proxy看到的是HOST ip，外面看到的是proxy設定的VIP)

第1,2的作法缺點就是只有一個HOST的ip，當然，多個domain name一個ip多個服務，使用traefik可以達成(後面會玩玩看)，但如何達成每個container有自己的WAN IP而且外面看得到?

看來只有macvlan是個機會。